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1 Introduction 

DiSOM [3, 4, 2] is a distributed shared memory system that offers users an atomic collection of 
memory cells provided they satisfy certain well-formedness conditions. This report proves the 
correctness of DiSOM. 

The system partitions memory into a set of objects and implicitly associates a read-write lock 
with each object. Users synchronize accesses to these objects explicitly executing synchronization 
operations on the associated locks. DiSOM's distributed read-write lock implementation guarantees 
progress and the usual read-write lock exclusion conditions. 

DiSOM guarantees an atomic view of memory provided: (1) all write accesses to an object's cells 
occur when the object's lock is acquired for writing; and (2) read accesses occur only when the lock 
is acquired for reading or writing. This model is similar to entry consistency [1] but it is simpler 
and provides an atomic memory instead of a sequentially consistent one. 

2 Interface 

DiSOM's memory consistency protocol is implemented by an asynchronous network system D with 
reliable FIFO channels. We assume there are n users U\,...,U n accessing the distributed shared 
memory and that D has one process Di corresponding to each user Ui. We call the composition of 
the user automata U. Informally, Ui communicates with Di using data access and synchronization 
operations. Data access operations read and write shared memory cells, whereas synchronization 
operations acquire and release the read-write lock associated with an object. This section defines 
the actions used for communication between I/O automata Ui and Di formally. 

It starts by introducing some preliminary definitions. Let C be the set of shared memory cells 
and V be the set of their values. A shared object is defined to be a subset of shared memory cells. 
Let O be the set of shared objects. We assume that the sets of cells corresponding to each object 
in O are pairwise disjoint. 

Di communicates with U using the following interface actions (in this definition v G V, c G C 
and o G O): 
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Input: 

(* data access input actions *) 
request-read (c)j 
request-write(c, v)i 

(* synchronization input actions 
request-acq- read(o)i 
request-rel-read (o) j 
request-acq- write(o)j 
request-rel-write(o)i 



Output: 

(* data access output actions *) 
reply-read(c, v)i 
reply-write(c)j 

(* synchronization output actions *) 
reply-acq-read (o) j 
reply- rel-read(o)i 
reply- acq- write ( o) j 
reply- rel-write(o)j 

We define corresponding request and reply actions to be actions with the same type (e.g request- 
acq-write and reply-acq-write) and the same cell or object (depending on whether they are data 
access actions or synchronization actions). An operation is a pair of consecutive corresponding 
request and reply actions in a trace. 

3 Correctness Conditions 

This section defines correctness conditions for system D x U. It starts by defining conditions on 
the user automata. We define a sequence (3 of actions from the interface above to be well-formed 
for user Ui if it satisfies the following conditions: 

1. (All operations are blocking) /3\i starts with a request action and every request action is 
immediately followed by a corresponding reply action (except possibly for the last request 
action in the sequence). 

2. (Synchronization operations are well formed) For any o 6 O, let 7 be the subsequence ob- 
tained from f3\i by removing all the data access actions and all the synchronization actions 
involving objects other than o. Then 7 is a sequence starting with either a (request-acq- write, 
reply-acq-write^) or a (request-acq- readj, reply-acq-readj) operations; such that every occur 
rence of (request-acq- writej, reply-acq-writej) is immediately followed by a (request-rel- write, 
reply-rel-write^) operation; and every occurrence of (request-acq- read^, reply-acq-readj) is im- 
mediately followed by a (request-rel-readj, reply- rel-readj) operation. 

We say that U satisfies the well-formedness condition if each Ui preserves the trace property 
defined by the set of sequences that are well- formed for Ui (according to the definition above). 
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Given a well- formed sequence of actions /3, an object o£0 and a user Ui, we say that U is: 

• in its remainder region for o, R(o), in between any reply- rel-write^ or reply-rel-read^ actions 
with argument o and the following request-acq-write^ or request-acq-readj actions with argu- 
ment o. 

• in its write trying region for o, T(o) w , in between any request-acq-write^ action with argument 
o and the corresponding reply action. 

• in its write critical region for o, C(o) w , in between any reply-acq-write^ action with argument 
o and the following request-rel-write^ with argument o. 

• in its write exit region for o, E(o) w , in between any request-rel-write^ with argument o and 
the corresponding reply action. 

T(o) r ,C(o) r and E(o) r can be defined in a similar way. With these region definitions we can 

define another well-formedness condition. 

Synchronized data accesses: We say that a sequence /3 of actions from the interface satisfies 
the synchronized data accesses condition for user U if the following holds. For any o G 0, let 7 be 
the subsequence obtained from /3\i by removing all the data access actions involving a cell d such 
that d £ o and all the synchronization actions involving objects other than o. Then 7 must satisfy 
the following conditions, for any applicable v G V and any c G o: 

1. A request-write(c, v)i action occurs only if U is in region C(o) w . 

2. A request-read(c)j action occurs only if Ui is either in region C(o) r or in region C(o) w . 

Intuitively, the last well-formedness condition restricts the contexts in which users are allowed to 
write or read from shared memory: (1) all write accesses to an object's cells must occur when the 
object's lock is acquired for writing; and (2) read accesses can only occur when the lock is acquired 
for reading or writing. We say that U satisfies the synchronized data accesses condition if each 
U preserves the trace property defined by the set of sequences that satisfy the synchronized data 
accesses condition for U (according to the definition above). 

We can now define correctness conditions for the entire system D x U . 

Well-formedness: In any trace of D x U, the subsequence describing the interaction between U 
and Di is well- formed for Ui. 

Exclusion: For any object o and any reachable system state of D x U, if some U is in C(o) w then 
no other user is in C(o) w or C(o) r . 

The last condition is the usual exclusion condition for read-write locks. It says that: (1) if user 
Ui has object o acquired for writing then no other user can have o acquired for writing or reading; 
and (2) if user U has object o acquired for reading then no other user can have o acquired for 
writing. 

Progress: At any point in a fair execution of D x U and for any object o G O: 

1. (Progress for the trying regions) If at least one user is in T(o) w (or T(o) r ) and no user is in 
C(o) w or C(o) r , then at some later point some user enters C(o) w or C(o) r . 



2. (Progress for the exit regions) If at least one user is in E(o) w (or E{o) r ) then at some later 
point some user enters R{6). 

We define the underlying variable type T of the shared memory implemented by D as follows. 
The set of values of T is V' c ', i.e. each state of a variable of type T is a tuple of values of V and 
each component in the tuple corresponds to a cell in C. Given an element w 6 V' ', we define w\c 
to be the component of w corresponding to cell c. The initial value of type T is (v , ...,v ). The 
set of invocations of T is X = {request-read(c) : Vc 6 C} \J {request-write(c, v) : Vc£C,« £ V} 
and the set of responses is 1Z = {reply-read(c, v) : Vc E C,v € V} U {reply-write(c) : Vc £E C}. 
The function / : I x V' c ' — > 1Z x V' c ' that defines T's behavior is defined as follows. Let w be 
an arbitrary element of V' c ', then /(request-read(c),u;) = (reply-read(c, w\c),w) and /(request- 
write(c, u),w) = (reply- write(c), w/), where w'\a = w\a, Va 6 C — {c} and w'\c = u. 

Atomicity: Let /3 be any well formed trace of D x U and 7 be the subsequence obtained from /3 
by removing all actions except data access actions. Then for each operation n in 7, it is possible 
to insert a serialization point * n between the request action of n and the reply action of n (if n is 
missing a reply action it must be possible to pick an appropriate reply action and insert * n after 
the occurrence of 7r's request); such that the sequence 7', obtained from 7 by moving the request 
and reply actions of each operation n to *„■ in this order, is a trace of T . 

We say that D is correct, if for every collection of users U that satisfies the well-formedness and 
synchronized data accesses conditions, D xU satisfies the well-formedness, exclusion, progress and 
atomicity conditions. 

4 Algorithm 

DiSOM's memory consistency protocol is implemented by an asynchronous send/receive system D. 
This section describes the algorithm implementing each process Di in D. Let V = {l,...,n} be 
the set of processes in D. We assume there is one universal reliable FIFO channel Cjj connecting 
process Di to Dj, for each j 7^ i in V . The first sub-section presents an informal description of the 
algorithm and the second presents a formal definition of each automaton Di. 

4.1 Informal Description 

The distributed read- write lock algorithm associates two types of tokens with each lock, the write 
token and the read token. For an acq- write operation on an object o to complete, the issuing process 
must hold o's write token. An acq-read operation will only complete if the process holds a read 
token. The algorithm ensures that: (1) if one process holds a write token for an object o then no 
other processes hold tokens for o; and (2) if one process holds a read token for o then no process 
holds a write token for o. This invariant ensures the exclusion condition. 

Each lock has an associated owner. The owner is either the process holding the write token or 
the last process to hold a write token. Ownership is dynamic, to keep track of the owner, each 
process maintains a forwarding pointer, probOwner(o), which points to the process it believes is the 
lock owner. The algorithm ensures that the owner can always be reached following the forwarding 
pointer chain. The owner process remembers which processes have obtained read tokens using the 
tokenSet(o) variable. The requests(o) queue is used to remember token transfer requests until 
they can be serviced. 



Processes cache tokens and can re-acquire locks with no communication as long as their token is 
not invalidated. When a process executes request-acq-write or request-acq-read and does not hold 
the needed token, a message is sent requesting the token. The message is sent along the forwarding 
pointer chain. A token can only be obtained from the owner. Therefore, forwarding stops when the 
message reaches the owner. As an optimization, if the request message reaches a process requesting 
a write token for the same object, the request is queued at that process. 

When a process receives a request for a write token that it holds, it waits until the lock is released 
by its user and then it replies with a message transferring the write token, the tokenSet(o) and 
the rest of the requests(o) queue to the requester. The owner then sets the forwarding pointer to 
point to the requester. When the requester receives the reply it prepends the queue of requests to 
its own. Then it sends messages to all the processes in the received tokenSet(o), invalidating their 
read tokens, and waits for the replies. 

When the owner receives a request for a read token and has a read token, the requesting process 
is inserted in tokenSet(o) and a reply is sent to it. The reply includes the read token and the owner 
identity. Thus all readers have their forwarding pointers set correctly. If the owner receives a read 
token request and it holds a write token, it proceeds as above but first converts its write token into 
a read token. 

DiSOM ensures the atomicity condition using an update protocol that piggy-backs the values of 
the cells in an object in the token transfer messages. 

4.2 Formal definition 

The messages used by the algorithm are elements of set M. defined next. 

M = ({reqWrite,reqRead,reqInv,repInv} x?x0) |J 
({repWrite} x V x O x 2 CxV x 2 V x Q) \J 
({repRead} xVxOx 2 CxV ) 



In this definition 0,C and V are the sets defined in Section 2, and Q is the set of all FIFO 
queues of elements of {(t,p) : t € {reqRead, reqWrite,reqInv},p 6 V}. We also define a function 
home : O — > V, which maps each object o to a fixed home process home(o). The I/O automaton 
for process Di has the following signature (in this definition DgV, c 6 C, o£0, m 6 M): 

Input: 

request-read(c), 
request-write(c, v)i 
request-acq-read(o), 
request-rel-read(o), 
request-acq-write (o) , 
request-rel- write (o) , 
receive(m)j i . 

Output: 

reply-read(c, v)i 

reply-write(c), 

reply-acq-read(o), 

reply-rel-read(o), 

reply-acq-write(o), 

reply-rel-write(o). 



send(m), i j 

Internal: 

reply-invalidate(o).; 

Each process maintains a status variable which keeps track of its computation status. This 
variable takes values in the set S defined next. 

Let S = ({repRead} x C x V) U 
({repWrite} x C) \J 

({repAcqRead, repRelRead, repAcqWrite, repRelWrite, replnvalidate, 
reqAcqRead, reqAcqWrite} x O) [j {idle} 

Di has the following state components: 
status £ S, initially idle 
For each o £ O, 

token(o) £ {read, write, none}, initially write in home(o) and none elsewhere 

held(o) £ {read, write, false}, initially false 

requests(o) € Q, initially empty 

tokenSet(o) £ 2 V , initially empty 

probOwner(o) € V , initially home(o) 
For each c G C, 

value(c) £ F, initially i>o 
For each j in V — {i} 

out(j) is a queue of elements of hA, initially empty 

Di has the following transitions: 
request-read(c). 
Effect: 

status := (repRead,c,value(c)) 

reply-read(c, v)i 
Precondition: 

status = (repRead, c, v) 
Effect: 

status := idle 

request-write (c, v)i 
Effect: 

value(c) := v 

status := (repWrite, c) 

reply-write(c). 
Precondition: 

status = (repWrite, c) 
Effect: 

status := idle 

request-acq-read(o). 
Effect: 

held(o) := read 



if (token(o) ^ none) then 

token(o) := read 

status := (repAcqRead,o) 
else 

append (reqRead,i,o) to out(probOwner(o)) 

status := (reqAcqRead,o) 

receive(repRead, i, o, u)j^ 
Effect: 

if (status = (reqAcqRead, o)) then 
for each (c, v) £ u do 

value(c) := v 
probOwner(o) := j 
token(o) := read 
status := (repAcqRead,o) 

reply- acq-read ( o) , 
Precondition: 

status = (repAcqRead, o) 
Effect: 

status := idle 

receive(reqRead, p, o)j t i 
Effect: 

if (probOwner(o) = i A held(o) ^ write) then 
tokenSet(o) := tokenSet(o) U {p} 
token(o) := read 
u:={} 
for each c £ o do 

«:=aU (c, i>aZwe(c)) 
append (repRead,p,o,u) to out(p) 
else if (probOwner (o) ^iA held(o) ^ write) then 

append (reqRead,p,o) to out(probOwner(o)) 
else 

append (reqRead,p) to requests(o) 

request-rel-read(o). 
Effect: 

held(o) := false 
status := (repRelRead,o) 
if (requests(o) is not empty) then 
(i,p) := first element of requests(o) 
remove first element of requests(o) 
if (probOwner(o) = i) then 
token(o) := none 
u:={} 
for each c £ o do 

u:=«U (c, i>aZwe(c)) 
append (repWrite,p,o,u,tokenSet(o),requests(o)) to out(p) 
tokenSet(o) := {} 
probOwner (o) := p 
else 

token(o) := none 



probOwner(o) := p 

append (repInv,p,o) to out(p) 

reply-rel-read(o). 
Precondition: 

status = (repRelRead, o) 
Effect: 

status := idle 

request-acq-write(o). 
Effect: 

held(o) := write 
if (probOwner(o) = i) then 
status := (replnvalidate, o) 
for each p € tokenSet(o) do 

append (reqInv,i,o) to out(p) 
else 

append (reqWrite,i,o) to out(probOwner(o)) 
status := (reqAcqWrite,o) 

receive(repWrite,i, o, u, t, r)jj 
Effect: 

if (status = (reqAcqWrite, o)) then 
for each (c, v) € u do 

value(c) := v 
pr obOwner (o) := i 
tokenSet(o) := t — {«} 
prepend r to requests(o) 
status := (replnvalidate, o) 
for each p € tokenSet(o) do 

append (reqInv,i,o) to out(p) 

reply-acq- write (o) , 
Precondition: 

status = (repAcqWrite, o) 
Effect: 

status := idle 

receive(reqWrite,p, o)^. 
Effect: 

if (probOwner(o) = i A held(o) = false) then 
token(o) := none 
u:={} 
for each c 6 o do 

«:=aU {(c, i>aZwe(c))} 
append (repWrite,p,o,u,tokenSet(o),requests(o)) to out(p) 
tokenSet(o) := {} 
pr obOwner (6) := p 
else if (probOwner(o) /iA held(o) ^ write) then 

append (reqWrite,p, o) to out(pr obOwner (o)) 
else 

append (regPFr«ie,p) to requests(o) 



request-rel- write (o) , 
Effect: 

held(o) := false 

status := (repRelWrite,o) 

u:={} 

for each cgodo 

u := uU (c, value(c)) 
while (requests(o) is not empty) do 

(t,p) := first element of requests (o) 
remove first element of requests(o) 
if (t = reqWrite) then 
token(o) := none 

append (repWrite,p,o,u,tokenSet(o),requests(o)) to out(p) 
tokenSet(o) := {} 
probOwner(o) := p 
break 
else 
token(o) := read 
tokenSet(o) := tokenSet(o) U {p} 
append (repRead,p,o,u) to out(p) 

reply-rel- write (o) , 
Precondition: 

status = (repRelWrite, o) 
Effect: 

status := idle 

receive (r eg Jni>, j, o)j t i 
Effect: 

if (held(o) ^ read) then 
token(o) := none 
probOwner(o) := j 
append (repInv,j,o) to out(j) 
else 

append (reqlnv,j) to requests(o) 

receive (replnv, i, o)jj 
Effect: 

if (status = (replnvalidate, o)) then 
tokenSet(o) := tokenSet(o) — {j} 

reply-invalidate (o) , 
Precondition: 

status = (replnvalidate, o) 

tokenSet(o) = {} 
Effect: 

token(o) := write 

status := (repAcqWrite,o) 

send(m)ij 

Precondition: 

m is first element of out(j) 
Effect: 



remove first element of out(j) 



Di has the following tasks: 
For each j £ V, 

{send(m), i j : Vm € M} 
and another task for all the other locally controlled actions. 



5 Proof of correctness 

We start by proving the well-formedness condition holds for any system D xU such that U satisfies 
well-formedness. Then we prove that exclusion and progress hold in the same conditions. The last 
subsection shows that D provides an atomic memory to any set of users U that satisfy both the 
well-formedness and the synchronized data accesses conditions. 

5.1 Well-formedness 

Theorem 1: If U satisfies the well-formedness condition then D x U satisfies the well-formedness 
condition. 

Proof: The status variable of each process i ensures that exactly one output reply action occurs 
in response to a request input action and that the two actions correspond. This combined with the 
fact that U satisfies well-formedness implies that D x U also satisfies well-formedness. 



5.2 Exclusion 

This section proves that the exclusion condition holds for any system D x U that satisfies well- 
formedness. The proof is based on the following auxiliary lemmas. 

Lemma 1: If D x U satisfies the well-formedness condition then, in any state of D x U , any o£0, 
any i E V, any j E V — {i}, and appropriate values of u, t and r, the following conditions are 
satisfied: 

1. If probOwner(o)i = i then probOwner(o)j ^ j 

2. If token(o)i = write then probOwner(o)i =t A tokenSet(o)i = {} 

3. If statusi = (replnvalidate, 6) then probOwner(o)i = i A held(o)i = write 

4. If statusi = (reqAcqWrite, 6) then held(o)i = write 

5. If statu si = (repAcqWrite,o) then token(o)i = write A held(o)i = write 

6. If (repWrite,j,o,u,t,r) is in Cjj or in out(j)i then Mp E V : probOwner(o) p ^p 

7. If (reqInv,i,o) is in Cij or in out(j)i then statusi = (replnvalidate, 6) 

8. If probOwner(o)i = i then token(o)i ^ none V statusi = (replnvalidate, 6) 
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Proof: By induction on the length of an execution. Fix any object o. 

Base case: The initializations ensure that Vi 6 V : probOwner(o)i = home(o), therefore (1) holds 

initially. The initializations also ensure that Vi G V : tokenSet(o)i = {}, token(o)f lome r ^ = write 

and Vi 7^ home(o) : token(o)i = none. Therefore (2) and (8) are also satisfied in the base case. (3), 

(4) and (5) are initially vacuously true because the status variables are initialized to idle. Since all 

channels are and all out variables are initially empty (6) and (7) are vacuously true. 

Inductive step: Assume the lemma holds for every state of any execution a of length at most /. We 

will show it holds for any one step extension a\ of a. 

The only way for (1) to be violated in a.\ is if in the last state in a there is a process % such that 
probOwner(o)i = i and some action of another process j is executed that sets probOwner(o)j = j. 
The only actions that can do this are actions of the form receive(repW rite, j, o, u, t, r) p j (for some 
p different from j). An action of this form can only occur if the appropriate message is at the head 
of channel C p j in the last state in a. Therefore, from the inductive hypothesis of (6), in this state, 
Vp G V : probOwner(o) p 7^ p. This is enough to conclude that actions of this form can not violate 

To prove (2), (3), (4), (5), (6), (7) and (8), we consider two cases (a) the antecedent is false in 
the last state of a and (b) the antecedent is true in this state. 

In case (a) the only actions that can violate (2) are those that set token(o)i = write, i.e. actions 
of the form reply-invalidate(o)i. Actions of this type are only enabled if statusi = (replnvalidate, o) 
therefore we can use the inductive hypothesis of (3) to conclude that if an action of this type occurs 
then probOwner(o)i = i A tokenSet(o)i = {} in the last state of a, which shows that (2) can not 
be violated in this case. 

In case (b), only actions that set probOwner(o)i 7^ i or set tokenSet(o) 7^ {}, and leave 
token(o)i = write can violate (2). The inductive hypothesis for (2) implies that probOwner(o)i = i 
in the last state of a. Therefore, only actions of the form veceive(repWrite, i, o, u, t, r)jj can violate 
(2) in this case. However, if one of these actions is enabled we can apply the inductive hypothesis of 
(6) and (2) to conclude that token(o)i / write in the last state of a, which violates our assumption 
for case (b). Therefore, (2) is satisfied in an. 

In case (a) only actions that set statusi = (replnvalidate, o) can violate (3), i.e. actions of the 
form request-acq-write(o)j and receive(repWrite,i, o, u,t, r)jj. The first type of actions can not 
violate (3), because they always set held(o)i = write and only set status = (replnvalidate, o) 
if probOwner(o)i = i. The second type of actions, only modify the state of i if statusi = 
(reqAcqWrite,o) and when they do so they set probOwner(o)i = i. Therefore, since these ac- 
tions do not modify held(o)i, we can use the inductive hypothesis of (4) to conclude that they do 
not violate (3) in this case. 

In case (b) only actions that set probOwner(o)i 7^ i or held(o)i 7^ write and do not modify 
statusi can violate (3), i.e. receive(reqWrite,p, o)j^ and receive(reqInv,j,o)jj. In case (b), from 
the inductive hypothesis for (4), held(o)i = write in the last state of a, therefore the first type of 
actions does not modify probOwner(o)i. Since, these actions never modify held(o)i, we conclude 
that they preserve the invariant in this case. For the last type of actions, the conditions of case 
(b) and the inductive hypothesis for (3) imply that probOwner(o)i = i in the last state of a. 
Therefore, we can use the inductive hypothesis of (1) to conclude that no other j 7^ i can have 
probOwner(o)j = j. Combining this with the inductive hypothesis of (3) and (7) we conclude that 
actions of the form receive(reqInv,j,o)jj can not violate (3) in case (b). 

In what concerns (4), in case (a) only actions of the form request-acq-write(o)j set status = 
(reqAcqW rite, 6) but they also set held(o)i = write. Therefore, (4) can not be violated in this 
case. In case (b) there is no action that sets held(o)i 7^ write without modifying statusi. Therefore, 
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(4) can not also be violated in this case. 

For (5), in case (a), the only actions that can violate the invariant are those that set statusi = 
(repAcqWrite,o), i.e. reply-invalidate(o)j. This action is only enabled if statusi = (repInvalidate,o) 
Therefore, the inductive hypothesis of (3) implies that held(o)i = write just before this action oc- 
curs. Since this action does not modify held(o)i and always sets token(o)i = write, we conclude 
that it preserves (5) in this case. 

In case (b), only actions that do not modify status and set token(o)i ^ write or held(o)i ^ 
write can violate (5), i.e. actions of the form receive(reqRead,p,o)jj, receive(reqWrite,p,o)jj, 
veceive(reqInv,j,o). Using the hypothesis of case (b) and the inductive hypothesis of (5), we 
conclude that the first two types of actions can not violate the invariant because held(o)i = write 
in the last state of a. The third type of action can not violate the invariant because the inductive 
hypothesis of (5), (2) and (7) imply that i can not receive a reqlnv message in this case. 

Only actions of the forms request-rel-read(o)j, receive(reqWrite, p, o)jj, and request-rel-write(o)i, 
can violate (6) in case (a). Actions of the first two types only append a repWrite message to an out 
variable if probOwner(o)i = i in the last state of a and when they do so they set probOwner(o)i ^ i. 
Therefore, we can apply the inductive hypothesis of (1) to conclude that they preserve the invariant 
in case (a). Well-formedness and the inductive hypothesis of (2) imply that the last type of actions 
can only occur when probOwner(o)i = i in the last state of a. Therefore, we can use the same 
argument to conclude that these actions also preserve the invariant in case (a). 

In case (b), we note that for a given object o there can be at most one (repWrite, j,o,u,t,r) 
message in a channel or out variable at any point in an execution. This is true because the actions 
that send such messages only do so if probOwner(o)i = i, and the inductive hypothesis of (6) 
implies that if there is such a message no process p has probOwner(o) p = p. Therefore, no process 
can send a message of this type while there is one in transit. The only actions that can violate (6) 
in this case are those of the type receive(repW rite, i, o, u, t, r)jj. However, using the invariant just 
proven we conclude that these actions preserve (6) in case (b) because they make the antecedent 
false. 

In case (a), the only actions that can violate (7) are actions that send reqlnv messages, i.e. 
actions of the form request-acq-write(o)j or ieceive(repWrite,i, o, u,t, r)jj. Actions of both types 
set statusi = (rep Invalidate, o) thus they preserve the invariant in this case. 

In case (b), all actions that set statusi 7^ (replnvalidate, o) can potentially violate (7). However, 
well-formedness prevents all request input actions from occurring. The inductive hypothesis of (7) 
together with the conditions for case (b) ensure that statusi = (replnvalidate, o) in the last state 
of a. Therefore, no reply output action is enabled. Therefore, the only actions that can potentially 
violate (7) in this case are of the form reply-invalidate(o)j. But these actions are only enabled if 
tokenSet(o)i = {} which in turn implies that there are no replnv messages in transit. Therefore, 
(7) holds in both cases. 

For (8), in case (a) only actions that set probOwner(o)i = i can violate the invariant, i.e. 
receive(repWrite,i, o, u,t, r)jj. However, these actions set statusi = (replnvalidate, o) and there- 
fore do not violate (8). 

In case (b), if statusi = (replnvalidate, o) well-formedness prevents the occurrence of any request 
action and of all output reply actions except for reply-acq-write(o)j (which is not enabled in this 
case). Therefore, the only actions that can set statusi 7^ (replnvalidate, o) are actions of the form 
reply-invalidate(o)j, but these actions also set token(o)i = write, thus they preserve (8). In case 
(b), if statusi 7^ (replnvalidate, o) in the last state of a then token(o)i ^ none in this state. In 
this case, the only actions that can violate the (8) are those that set token(o)i = none, but all of 
these actions set probOwner(o)i ^ i and doing so preserve (8). 



12 



Lemma 2: If D x U satisfies the well-formedness condition then, in any state of D x U, for any 
o£0, any i, j,p E V such that i ^ j A i ^ p A j ^ p, and for appropriate values of u, v, t and r 
the following conditions are satisfied. 

1. If statu si = (r eq Acq Read, 6) then held(o)i = read A token(o)i = none 

2. If statu si = (repAcqRead,o) then held(o)i = read A token(o)i = read 

3. If there is a (repRead,j,o,u) in Cij or out(j)i then (i) probOwner(o)i = i Aj E tokenSet(o)i 
or (ii) probOwner(o)i = p A status p = (replnvalidate, o) Aj E tokenSet(o) p or (iii) there is 
one (repWrite,p, o, v, t, r) message in out(p)i or Cj iP such that j €. t and probOwner(o)i = p. 

4. If token(o)j = read then (i) probOwner(o)j = j or (ii) probOwner(o)i = iAj E tokenSet(o)i 
or (iii) there is one (repWrite,p,o,v,t,r) message in out(p)i or Cj iP such that j E t. 

5. If probOwner(o)i = i A token(o)j = read then j E tokenSet(o)i. 

6. If there is a (repInv,j,o) message in Cjj or out(j)i then token(o)i = none A status j = 
{replnvalidate, o) A there is no (repRead, i, o, u) in C q ^ or out(i) q for any g E "P. 

Proof: We start by noting that (4) and parts (1) and (6) of lemma 1 imply (5). We prove the rest 
of the lemma by induction on the length of an execution. Fix any object o. 

Base case: The initializations ensure that statusi is initially idle. Therefore, (1) and (2) are 
vacuously true in the base case. The initializations also ensure that token(o)i ^ read for any i E V 
and that the channels and out variables are empty. Therefore, (3), (4) and (6) are also true in the 
base case. 

Inductive step: Assume the lemma holds for every state of any execution a of length at most /. 
We will show it holds for any one step extension a.\ of a. 

We consider two cases in the proofs, (a) the antecedent is false in the last state of a and (b) the 
antecedent is true in this state. 

For (1), in case (a) the only actions that can potentially violate the invariant are those that set 
statusi = (reqAcqRead,o), i.e. request-acq-read(o)j. However, these actions always set held(o)i = 
read and only set statusi = (reqAcqRead, o) if token(o)i = none. Therefore, they do not violate 

In case (b), there are no actions that set held(o)i ^ read without modifying statusi. The 
only actions that can set token(o)i ^ none without modifying statusi are actions of the form 
veceive(reqRead,p, o)jj, but part (8) of lemma 1 together with the conditions for case (b) implies 
that probOwner(o)i ^ i in the last state of a and thus these actions can not modify token(o)i and 
the invariant holds. 

In what concerns (2), in case (a), the only actions that can potentially violate the invariant are 
those that set statusi = (repAcqRead,o), i.e. request-acq-read(o)j and receive(repRead,i,o,u)jj. 
The first type of action always sets held(o)i = read and when it sets statusi = (repAcqRead, o) 
it also sets token(o)i = read. Therefore, (2) is preserved by this type of actions in this case. 
The second type of actions only modifies the state of i, if statusi = (reqAcqRead, o) in the last 
state of a and always sets token(o)i = read in this case. Using the inductive hypothesis of (1) 
we conclude that this type of actions also preserves (2) in case (a). In case (b), only actions that 
do not modify statusi and set held(o)i ^ read or token(o)i ^ read can potentially violate (2), 
i.e. veceive(reqWrite,p,o)j^ and veceive(reqlnv,j, o)jj. In case (b) the inductive hypothesis of (2) 
implies that held(o)i = read, therefore actions of these types can not violate (2) in case (b). 
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For (3), in case (a), only actions that put a repRead message in out(j)i can violate the invariant, 
i.e. actions of the forms receive(reqRead,j,o) q j or request-rel-write(o)j. The first type of action 
only sends a repRead message if probOwner(o)i = i, it does not modify probOwner(o)i and it 
inserts j in tokenSet(o)i. Therefore, this type of action preserves the invariant. Well-formedness 
and part (2) of lemma 1 imply that the second type of actions can only occur if probOwner(o)i = i. 
Also note that these actions insert the indices of the processes to which repRead messages are sent 
in tokenSet(o)i. We distinguish two cases (a.l) requests(o)i contains a reqWrite request or (a.2) 
it does not. In case (a.l) let (reqWrite, p) be the first write request in requests(o)i, then (iii) will 
hold after the action executes. In case (a.2), (i) will hold after the action executes. Therefore, 
actions of this type also preserve (3) in case (a). 

In case (b) for (3), we note that only one of (i) to (iii) can be true at any point in an execu- 
tion. This is so because of lemma 1 parts (1), (3) and (6). We consider 3 cases (b.l) to (b.3) 
corresponding to exactly one of (i) to (iii) being true in the last state of a. In case (b.l), only 
actions that set probOwner(o)i ^ i or remove j from tokenSet(o)i can potentially violate (3), 
i.e. receive(repRead,i,o,u)jj, request-rel-read(o)i, receive(reqWrite,p, o)^, request-rel-write(o)i, 
receive(reqInv,j,o)jj and receive(replnv,i, o)^. Actions of the form receive(repRead,i,o,u)jj 
only have effects if statusi = (reqAcqRead,o). Since in this case probOwner(o)i = i in the last 
state of a, part (8) of lemma 1 and (1) imply that these actions can not violate the invariant in this 
case. Actions of the forms request-rel-read(o)j, receive(reqWrite, p, o)j^ or request-rel-write(o)j do 
not violate (3) in this case, because when they modify probOwner(o)i they ensure that (iii) is 
true just after they execute. Actions of the form receive(reqlnv,j, o)j^ can not occur in case (b.l) 
because of parts (1) and (7) of lemma 1. Finally, receive(rep/ra;,i, o)^ does not violate (3) in this 
case because according to the inductive hypothesis of (6) it can not occur in this case. In case 
(b.2), well-formedness and lemma 1 imply that only receive(replnv,i, o)^ can violate (3) in this 
case. However, part (4) of lemma 1 implies that probOwner(o) p = p in the last state of a, therefore 
we can apply the inductive hypothesis of (6) to conclude that it can not occur in this case. In case 
(b.3), only actions that consume the repWrite message can violate (3), but these actions ensure 
that (ii) is true just after they execute. Therefore, we conclude that (3) holds in all cases. 

For (4), in case (a), only actions that set token(o)j = read can violate the invariant, i.e. request- 
acq-read(o)j, request-rel-write(o)j, and receive actions corresponding to the arrival of a reqRead or 
repRead message to j. In case (a), actions of the form request-acq-read(o)j only set token(o)j = 
read if in the last state of a token(o)j = write, which in turn implies (part (2) of lemma 1) that 
probOwner(o)j = j. Therefore, these actions preserve (4) in case (a). Well-formedness and lemma 
1 imply that request-rel-write(o)j actions can only occur if probOwner(o) j = j and when these 
actions set token(o)j = read they do not modify probOwner(o)j. Therefore, these actions also 
preserve (4) in this case. A similar reasoning can be used to show that the arrival of a reqRead 
message at j preserves (4). The last type of actions also preserves (4) because of the inductive 
hypothesis of (3). 

To prove (4) in case (b), we consider 3 cases (b.l) to (b.3) corresponding to exactly one of (i) 
to (iii) being true in the last state of a (using the same argument as we did for (3)). In case (b.l), 
(4) can be violated by actions that set probOwner(o)j / j, i.e. request-rel-read(o)j, request-rel- 
write(o)j, and the arrival of a reqWrite, reqlnv, or repRead message at j. All the actions except 
the last preserve the invariant because they set token(o)j = none when they modify probOwner(o) j . 
The last type of actions only modifies the state of j if status j = (reqAcqRead, o), in the last state 
of a, but the inductive hypothesis of (1) implies that this can not happen in this case. Therefore, 
(4) holds in case (b.l). Arguments similar to those used in cases (b.l) and (b.3) for (3), show that 
(4) also holds in cases (b.2) and (b.3). 
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For (6), in case (b), the only actions that can potentially violate the invariant are those that 
append a (repInv,j,o) message to out(j)i, i.e. request-rel-read(o)j and receive((reg/n'U, - ;, o)^). 
We note that they both set token(o)i = none when they send a (replnv, j, o) message. These 
actions only send a replnv message in reply to a reqlnv message. Part (7) of lemma 1 implies 
that status j = (replnvalidate, 6) when the reqlnv message is received and inspecting the code we 
conclude that status j retains its value until all the relevant replnv replies arrive. Well-formedness 
implies that there can only be a (repRead, i, o, u) message in transit if statusi = (reqAcqRead, 6) 
and (1) implies that held(o)i = read in this case. Since, the actions that send (replnv, j, o) messages 
are either not enabled for this statusi value or do not send the reply message if held(o)i = read, 
we can conclude that the invariant is preserved in case (a). In case (b), we note that token(o)i 
can only become different from none if a repRead or repWrite message for object o is received 
by i. However, the inductive hypothesis prevents this from happening for repRead messages and 
lemma 1 prevents this from happening for repWrite messages, status j can only become different 
from (replnvalidate, o) if all replnv replies are received. Finally, from lemma 1, if status j = 
(replnvalidate, o) then held(o)j = write A probOwner(o)j = j, therefore no (repRead, i,o,u) will 
be sent while statusj = (replnvalidate, o). 

Theorem 2: HDxU satisfies the well-formedness condition then it satisfies the exclusion condition. 

Proof: For any object o£0 and any i 6 V . From well-formedness and the definition of C(o) w , XJ{ 
enters C(6) w when a (request-acq-writej, reply-acq-writej) operation on o completes and exits this 
region when a request-rel-write^ action, n, on o occurs. From part (5) of lemma 1, held(o)i = write 
and token(o)i = write just after Ui enters C(o) w . Well-formedness and lemma 1 imply that 
held(o)i = write and token(o)i = write until n. Therefore, we conclude that (a) if Ui is in C(o) w 
then held(o)i = write and token(o)i = write. 

A similar argument can be used for C(o) r . U enters C(o) r when a (request-acq-read^, reply- 
acq-readj) operation on o completes and exits this region when a request-rel-readj action, 6, on o 
occurs. From part (2) of lemma 2, held(o)i = read and token(o)i = readjust after Ui enters C(o) r . 
Well-formedness and the fact that held(o)i = read ensure that token(o)i and held(o)i retain these 
values until 8 occurs. Therefore, (b) if U is in C(o) r then held(o)i = read and token(o)i = read. 

Assertion (a) and part (2) of lemma 1 imply that (c) if Ui is in C(o) w then probOwner(o)i = 
i A tokenSet(o)i = {}. Assertion (c), part (1) of lemma 1 and part (5) of lemma 2 imply that if 
some Ui is in C(o) w then no other user is in C(o) w or C(o) r , as desired. 

5.3 Progress 

This section shows that if a system D x U satisfies well-formedness, then D x U also satisfies 
progress. We start by proving some auxiliary lemmas. 

Lemma 3: In any well-formed fair execution a of D x U , if at some point in a a message m is 
appended to out(j)i then eventually a receive(m)ij occurs. 

Proof: Implied by fairness of a. 

Lemma 4: In any well-formed fair execution a of D x U, if at some point in a no user is in C(o) w 
or C(o) r and some process i appends a (reqlnv, i,o) message to out(j)i then i eventually receives 
a (replnv, i,o) message in Cjj, or some user enters C(o) w or C(o) r . 
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Proof: Fix any object o£0 and any well-formed fair execution a of D x U . Lemma 3 implies that 
a receive(reqInv,i,o)ij occurs at some later point in a. We consider two cases (a) held(o)j ^ read 
at this point and (b) held(o)j = read. In the first case the receive action appends a (repInv,i,o) 
message to out(i)j. Once more lemma 3 implies that eventually a receive(replnv,i, o)j^ occurs 
and therefore the lemma holds in this case. In case (b), Uj is in T(o) r or C{o) r . If Uj is in C(o) r 
the lemma holds. Therefore, consider the case where Uj is in T{o) r . In this case, if status j ^ 
(reqAcqRead, 6) then fairness of a implies that Uj will eventually enter C(o) r . Otherwise, since 
j is receiving an invalidation request, there must be a (repRead,j,o) message in transit. Lemma 
3 implies that j will receive a (repRead,j,o) message that will set statusi = (r ep Acq Read, o). 
Therefore, by fairness Uj will eventually enter C{o) r and the lemma also holds in this case. 

Lemma 5: If D x U satisfies well-formedness then in any reachable system state and for any i E V, 

the path denned by the following sequence of nodes 

probOwner(o)i,probOwner(o) proh0wner{o) .,... 

connects i to a node j such that exactly one of the following holds: (i) probOwner(o)j = j or (ii) 
there is a (repWrite, j,o,u,t,r) message in out(j)f. or C^j, and k is the node just before j in the 
path. 

Proof: By induction on the length of an execution. Fix any object o£0. 

Base case: The initializations ensure that the lemma holds initially by setting probOwner(o) p = 
home(o),\/p E V. 

Inductive step: Assume the lemma holds for every state of any execution a of length at most 
/. We will show it holds for any one step extension c\\ of a. The only actions that can violate 
the invariant are those that modify probOwner(o)i for some i E V, i.e. receive(repRead,i,o,u)jj, 
request-rel-read(o)i, receive(repWrite,i, o, u,t, r)jj, receive(reqWrite, p,o)jj, request-rel-write(o)i 
and receive(reqInv,j,o)jj. The first type of actions sets probOwner(o)i = j. From lemma 1 
and part (3) of lemma 2, either (a) probOwner(o)j = j , or (b) there is a repWrite message 
in transit from j to another process p for object o and probOwner{6) j = p, or (c) there is a 
process p such that probOwner(o) p = p and probOwner(o)j = p. Therefore, the inductive hy- 
pothesis of the lemma implies that the first type of actions preserves the invariant. Actions of 
type request-rel-read(o)j, preserve the invariant when they send a repWrite message to a process 
p because of the inductive hypothesis and the fact that they set probOwner(o)i = p. (For the 
same reason receive(reqWrite,p, o)j^ and request-rel-write(o)j also preserve the invariant). It re- 
mains to show that actions of the form request-rel-read(o)i preserve the invariant when they do 
not send a repWrite message. We note that in this case they send a replnv message to a pro- 
cess p and set probOwner(o)i = p. Therefore, we can apply part (6) of lemma 2 and part (3) 
of lemma 1 to conclude that they also preserve the invariant in this case. Actions of the form 
receive(repWrite,i,o,u,t,r)jj, preserve the invariant because of the inductive hypothesis and the 
fact that they set probOwner(o)i = i. Finally, parts (3) and (7) of lemma 1 and the inductive 
hypothesis imply that receive(reqInv,j,o)jj also preserve the invariant. 

Lemma 6: In any well-formed fair execution a of D x U for any o E O and any i,p E V, if i 
receives a (reqRead,p, 6) (or (reqWrite,p, o)) message at some point in a when probOwner(o)i = i 
and no user is in C(o) w or C(o) r , then at some later point in a a receive(repRead,p,o,u)i tP (or a 
receive(repWrite,p,o,u,t,r)i tP ) occurs or some user enters C(o) w or C(o) r . 
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Proof: We first consider the case of a (reqRead,p,o) message. If probOwner(o)i = i when a 
veceive(reqRead,p, o)jj is executed (for some j 6 V), then either (a) held(o)i = write or (b) 
held{o)i 7^ write. In case (a) i appends a (repRead,p,o,u) to out(p)i and lemma 3 implies that 
the lemma holds. In case (b) U is in T(o) w or C(o) w . In the latter case the lemma also holds. 
In the former case, we can use fairness and lemma 4 to conclude that the lemma also holds. For 
a (reqWrite,p,o) message, if probOwner(o)i = i when a receive(reqWrite, p, o)j^ is executed (for 
some j €?), then either (c) held(o)i = false or (d) held(o)i / false. Using an argument similar 
to the one in the previous paragraph it is easy to see that the lemma holds in case (c). In case 
(d), Ui is in T(o) w , C(o) w , T(o) r or C(o) r and once more an argument similar to the one presented 
before shows that the lemma also holds in this case. 

Lemma 7: In any well- formed fair execution a of D x U, if i sends a (reqRead,i,o) (or (reqWrite,i, 
o)) message, m, at some point in a when no user is in C(o) w or C(o) r , then at some later point 
in a the message is received by a process j such that probOwner(o)j = j, or some user U p (p ^ i) 
enters C(o) w or C(o) r . 

Proof: By observing the code for receive(reqRead,i, o) q ^ p and receive(reqWrite,i,o) qtP , we con- 
clude that forwarding of m stops if one of these actions is executed and held{o) p = write or 
probOwner(o) p = p. Furthermore, lemma 3 and lemma 5 imply that m eventually reaches such a 
process p. We consider 2 cases depending on the state of process p when forwarding of m stops, (a) 
probOwner(o) p = p and (b) probOwner(o) p ^ p. If case (a) occurs the lemma holds, therefore con- 
sider case (b). In this case, it must be that held{o) p = write, therefore p has sent a (reqWrite,p, o) 
message to probOwner(o) p . We can use the same argument as before to conclude that forward- 
ing of this message stops when the message reaches a process q such that held{o) q = write or 
probOwner(o) q = q. We can continue this reasoning using the same arguments as above. We argue 
that it is not possible for all requests to be blocked at a process with held{o) = write because of 
lemma 5. Therefore, the lemma holds. 

Theorem 3: If D x U satisfies the well-formedness condition then it satisfies the progress condition. 

Proof: Fix any object o 6 O and any fair execution a of D x U . We start by proving progress 
for E{o) r . By definition a user Ui enters E(o) r when a request-rel-read(o)j occurs. This action 
sets statusi = (repRelRead,o) enabling reply-rel-read(o)i. Since statusi retains this value until 
reply-rel-read(o)i occurs, fairness of a implies that this action occurs, i.e. that U enters R(o) at 
same later point in a. An identical argument holds for E{o) w . Therefore, the theorem holds for 
the exit regions of any object o. 

We now show progress for T{o) r . By definition a user Ui enters T{o) r when a request-acq- 
read(o)j occurs. Observing the code for request-acq-read(o)j, we conclude that if token{o)i / none 
this action sets statusi = (repAcqRead, o) enabling reply-acq-read(o)i. Once more fairness of a 
implies that reply-acq-read(o)j eventually occurs. Therefore, progress holds in this case. In the 
other case (token(o)i = none) a (reqRead,i,o) message is appended to out(probOwner(o)). At 
this point we can apply lemmas 6 and 7 to conclude that progress also holds in this case. 

To show progress for T(o) w , we note that by definition a user Ui enters T(o) w when a request- 
acq-write(o)j occurs. If probOwner(o)i = i when this action occurs then this action sets statusi = 
(repInvalidate,o) and appends (reqInv,i,o) messages to out(p)i (for every p 6 token Set(o)i). If 
some user is in C(o) w or C(o) r at this point the lemma holds, therefore assume there is no such user. 
Lemma 4 says that i eventually receives a reply to each reqlnv message or some user enters C(o) w 
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or C(o) r . In the latter case the theorem holds. In the former case, receive(rep/ra;, i, o) p j will be exe- 
cuted repeatedly and tokenSet(o)i will eventually become empty enabling reply- invalidate (o)j. Fair- 
ness implies that this action eventually occurs and sets statusi = (repAcqWrite,o). Therefore, Ui 
eventually enters C(o) w and the lemma also holds in this case. In the other case (probOwner(o)i ^ i 
when the request-acq-write(o)j occurs), a (reqWrite, i, 6) message is appended to out(probOwner(o)) . 
At this point we can apply lemmas 6 and 7 to conclude that the theorem holds. 

5.4 Atomicity 

In this section, we show that if U satisfies the well-formedness and synchronized data accesses 
conditions, then D x U also satisfies the atomicity condition. 

Lemma 8: If U satisfies the well-formedness and synchronized data accesses conditions then for 
any execution (3 of D x U, any i E V and any o E O, when a reply-acq-write(o)j (or reply-acq- 
read(o)j) action n occurs in /3 the following holds: Vc E O : if request-write(c, v)j is the last 
request-write action with argument c that precedes n in (3 then value(c)i = v or, if there is no such 
action, value(c)i = v . 

Proof: By induction on the number of reply-acq-write(o) actions that precede n in an execution 

Base case: Zero occurrences of reply-acq-write(o) actions before point n in f3. The synchronized 
data accesses condition together with the fact that the sets in O are pairwise disjoint imply that 
no request-write(c, v)j can occur before n for any c E o,j E V and v E V. Therefore, we must 
show that if a reply-acq-write(o)j (or reply-acq-read(o)j) action occurs at point n in f3 then, at this 
point, V E c : value(c)i = v . This holds because the initializations ensure that Vc E C,p E V : 
value(c) p = v . 

Inductive step: Assume the lemma holds up to point n where the l-th reply-acq-write(o) occurs 
in j3. We will show it also holds at point TT2 just after the the l+l-th reply-acq-write(o) (if it exists) 
and just after any reply-acq-read(o) between n and 7T2. 

Assume the l-th reply-acq-write(o) occurs at port j leading Uj into C(o) w . The exclusion condi- 
tion says that no reply-acq-write(o)i (or reply-acq-read(o)i) can occur at any port i until a request- 
rel-write(o)j occurs. If this request-rel-write(o)j never occurs in /3 then the lemma holds. Therefore, 
assume it occurs at point n\ in f3. 

We note that for any cell c E o, value(c)j can only change if an action of one of the following forms 
occurs: request-write(c, v) j , receive(repWrite, j, o,u,t, r) p j and receive(repRead, j, o, u) p j . We 
also note that well-formedness prevents status j from being equal to (reqAcqRead, o) or (reqAcWrite, 
o) while Uj is in C(o) w . Therefore, actions of the last two types can not modify the values of cells in 
o between points n and 7i"i. The synchronized data accesses and exclusion condition together with 
the fact that elements of O are pairwise disjoint, imply that no request-write(c, v) p , for p ^ j can 
occur between n and 7i"i. These claims together with the inductive hypothesis imply that Vc E O 
if request- write(c, v) j is the last request- write action with argument c that precedes tt\ in (3 then 
value(c)j = v or, if there is no such operation, value(c)j = v . 

The synchronized data accesses condition and the fact that elements of O are pairwise disjoint 
prevents actions of the form request-write(c, v) p (Vc E o,p E V) from occurring between tt\ and TT2- 
Therefore, to show the lemma holds for the l+l-th reply-acq-write(o)j and all reply-acq-read(o)i 
actions between n and 7T2, we must show that when any of these actions occurs for any cell c E o 
value(c)i is equal to value(c)j at point 7i"i. 
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Claim 1: The proof of theorem 1 shows that if Uj is in C(o) w then token(o)j = write and held(o)j = 
write. Prom lemma 1 this implies that if Uj is in C(o) w then probOwner(o)j = j. Observing the 
code for request-rel-write(o)j, we conclude that probOwner(o)j = j at point it\. We argue that 
probOwner(o)j retains its value up to the point n^ where j sends a repWrite message for object o 
to another process. The only actions that can violate this are prevented from doing so by the fact 
that probOwner(o)j = j (as shown by lemmas 1 and 2). Furthermore, when j sends a repWrite 
message to another process p, it sets token(o)j = none and probOwner(o)j = p. From lemma 1 
it must acquire a write token for o from another process, before a subsequent reply-acq-write(o)j 
occurs. Lemma 1 implies that p has held(o) p = write at point ir[ and will keep held(o) p = write 
until after a reply-acq-write(o) p occurs. Therefore, after point tt[ no token transfer requests will be 
serviced until after a reply-acq-write(o) p occurs. 

Consider two cases (a) the l+l-th reply-acq-write(o) operation occurs at port j and (b) it does 
not. Claim 1 implies that in case (a) ir[ must occur after 7T2. We argue that value(c)j (Vc 6 o) is 
not modified between 7i"i and TT2 in this case. This is so because, as discussed above, no request- 
write^, v)j (Vc 6 o) can occur, and the fact that probOwner(o)j = j and lemmas 1 and 2 imply 
that the arrival of repRead and repWrite messages can not change the values of the cells in o. 
Therefore, the lemma holds in this case for the l+l-th reply-acq-write(o) operation. We will also 
show it holds for all the reply-acq-read(o)i operations between n and tt2- We consider two cases 
(a.l) i = j and (a.2) i / j. The lemma holds in the first case as discussed earlier. In case (a.2), a 
reply-acq-read(o)j can only occur (from lemma 2) if token(o)i = read and since token(o)i = none 
at point 7i"i (from lemma 1 and the fact that token(o)j = write), i must receive a repRead message 
from j. This message must be sent before Ti2 and after tti, therefore it will carry the state of the 
cells of o at j at point 7i"i. The receive action for this repRead message ensures that the lemma 
holds by setting the value of each cell of o in i equal to the value received in the message. 

In case (b), the l+l-th reply-acq-write(o)j can only occur if token(o)i = write (lemma 1) and 
since token(o)i = none at point tti (from lemma 1 and the fact that token(o)j = write), i must 
receive a repWrite message from j. This message is sent at point n[. We can use an argument 
identical to that in case (a) to conclude that value(c)j (Vc 6 o) is not modified between 7i"i and n^. 
Therefore, the message will carry the state of the cells of o at j at point 7i"i and like in the read case 
the receive action ensures that the lemma holds. To show it also holds for all the reply-acq-read(o)i 
operations between n and iT2, we note that any repRead message enabling such an action must be 
sent between 7i"i and n^. Therefore, we can use the same argument we used in cases (a.l) and (a.2) 
to complete the proof of the lemma. 

Theorem 3: If U satisfies the well-formedness and the synchronized data accesses conditions then 
D x U satisfies the atomicity condition. 

Proof: We pick as serialization point for each (request-read(c)j, reply-read(c, v)i) operation the 
point where the reply- read(c, v)i action occurs in 7. Similarly, for each (request-write(c, v)i, reply- 
write(c)j) operation, we pick as serialization point the point where the request-write(c, v)i action 
occurs in 7. It is clear that the serialization point for each operation is between its request and 
reply actions, as required. For incomplete operations we pick the point where the request action 
occurs as the serialization point and for read operations we pick as response value(c)i at that point. 
We must now show that the sequence 7', obtained from 7 by moving the request and reply actions 
of each operation op to * op in this order, is a trace of T. From the definition of T, it is enough to 
show that each reply-read(c, v) in 7' returns the value v written by the last request-write(c, v) that 
precedes the read in 7' (or v = v if there is no such action). 
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We note that with the serialization points chosen the relative order between the reply-read(c, v) 
actions and the request- write(c,'u) actions is identical in 7' and /3. Therefore, we can use lemma 
8 to prove the theorem. Lemma 8, the well-formedness, synchronized data accesses and exclusion 
conditions together with the fact that the sets in O are pairwise disjoint imply the theorem. 

6 Complexity analysis 

In this section we analyse the number of messages sent and the time elapsed between the occurrence 
of a request-acq-write(o)j (or request-acq-read(o)j) and the corresponding reply-acq-write(o)i (or 
reply-acq-read(o)j). We consider only the case of an isolated request, i.e. we assume that between 
the point where the request occurs and the point where the reply occurs status p = idle (for all 
p 6 V — {«}), and that no user is in C(o) w or C(o) r . 

The maximum number of messages sent between the occurrence of a request-acq-read(o)j and 
the corresponding reply under these conditions is n. This case occurs if the path defined by the 
probOwner(o) variables starting at i has maximum length. In this case, it takes n — 1 messages 
for the request to reach the process j such that probOwner(o)j = j plus the reply sent by j to i. 
For a request-acq-write(o)j, the worst case message complexity occurs if the path defined by the 
probOwner(o) variables that connects i to j (such that probOwner(o)j = j) has length 2 and there 
are n — 2 processes different from i and j that have token(o) variables equal to read. In this case, 
it takes 3 messages for i to receive its reply, and 2(n — 2) messages to invalidate the n — 2 read 
tokens. Note that processes that have token(o) = read have their probOwner(o) variables pointing 
directly to the owner, therefore this is really the worst case. 

For the time complexity analysis, we assume that / is an upper bound on time for each process 
task and d is an upper bound on the time to deliver the oldest message in a channel. The maximum 
time between the occurrence of a request-acq-read(o)j and the corresponding reply occurs in the 
same scenario as the worst case message complexity for this type of request. Therefore, the total 
elapsed time is n(d + I). For a request-acq-write(o)j, the worst case time complexity does not 
occur for the same scenario as the worst case message complexity because invalidations proceed in 
parallel. In the worst case scenario, the path defined by the probOwner(o) variables has maximal 
length and the next to last process in the path has token(o) = read. The time complexity in this 
case is (n + 2)(d + 1). n(d + I) time for a repWrite message to arrive at i and 2(d + I) to invalidate 
the read token. 
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